2018.01.22 - 2018. 03.30, 我在某车厂Iot Paas项目上做前端dev。这是我第一个经历了完整研发周期的项目，在各个阶段遇见不同的种类的困难，带来很多不一样的体验。
对于前端，这个项目并没有很复杂的业务逻辑，核心的功能就是数据的增删改查。并且前端技术栈采用的是我比较熟悉的vue，所以在单纯的业务卡上并没有遇到很多挑战，几乎可以说是平稳进行的。所以我把更多精力放在代码质量以及对vue的深度使用上。
我做了什么：
- 20个通用组件。
写通用组件是我比较喜欢的任务，因为通用组件就意味着不带任何业务逻辑，不对外部做任何预设，保证组件对外的简单易用，易扩展等等…写通用组件让我觉得自己是个设计师（笑。其实在前端组件化的context之下，写通用组件就是写类。 - N多业务组件
对于这个项目，在通用组件写好的情况下，业务组件是相对简单的， 它只是按照需求将通用组件组合起来使用。但在业务组件中，也存在可以抽成一个通用业务组件的情况。比如我们的新建和修改使用的是同一个popup，区别只在于一个初始化时有数据，一个初始化时无数据，以及发送的请求methods不一样而已。这时我们就可以将这个popup写得更通用一些，使得N个功能都可以使用这同一个组件。 - 修改整体layout和路由
项目刚开始的时候给自己挖了个大坑，全局观不好，以至于后续需要大概layout。同时对vue-router和vuex某些特性的错误判断，导致在解决这个问题的时候，跑错了很多路。这部分会在vue的总结中详述。 - 抽方法
通过各种方式减少代码重复：抽utils按需引入,filter,mixin,全局注册,vuex…这里我觉得思路比较好的是将loading和error抽出。其实这个思路是从上个项目中踩的坑来的。上个项目中，在上线前不久才发现，整个前端没有在向后端请求过程中加loading以阻止用户的其他操作。因此在这个项目已开始，我们就对每个请求加上了loading。后来发现请求的错误处理也大多保持一致的行为，所以也把errorHandler抽成vuex。但此时发现，即便将其抽到vuex，也还是需要在每次请求的时候都调用一次，我就开始向能否在某个地方统一处理一次即可。最后，我们将loading和error的调用写在了axios提供的返回拦截器中。最后就变成了：逻辑写在vuex中，调用写在返回拦截器中。 - 选择和使用第三方库
项目中有三处需要借助第三方库来实现功能：展示并高亮显示json, 编辑json并实时高亮，markdown loader。
第一个只是静态展示json，在stack overflow上看到别人写的一个函数就可以完美实现，于是我按照vue的思路造了一个通用组件出来。第二个就复杂了，她其实是个在线json编辑器，还需要实时高亮，缩进正确。开始的时候在git上找到用vue写的两个库，但都需要在他们实现的基础上tricky的hack，并且对于我们的需求来说，他们都太重了。于是我试图去找更轻量化的，不需要hack的库。然后我去研究其中一个项目的源码，发现我们所需要的功能，他的代码中写的十分简单，完全看不出来通过这些代码就可以实现功能的样子。再进一步研究惊喜的发现，他也是引入了别人的库来实现在线编辑功能。于是我顺藤摸瓜最后摸到了我们需要的库：亚马逊的ace，在线代码编辑器， git上15K个star。最后，我们只引入了这一个基础库，通过它提供的配置选项优雅地实现了需求。第三个于此经历相似，也是顺藤摸瓜。这个经历给我的震撼还是蛮大的。以前找第三方库的时候完全没有头绪，现在就信心很大，并且有一套方法去找到我们的目标。还有一点很重要就是，要相信这些很普遍的需求，一定会有一个很好的库来实现的。 - 帮QA解决自动化测试脚本中的代码问题
这个印象很深，是因为QA跑测试的时候有个没通过，以为是个bug过来问我。我觉得不应该通不过，于是猜测可能是脚本写的有问题，就去看了她的代码，发现果然如此。场景是数据修改，修改后判断页面上显示已经修改后的文字。然而在写测试的时候，她是同步的去写的，修改后马上做断言。真正的流程是异步的，应该在修改请求成功后再做断言。后来我们再发请求之后强行sleep3秒之后再做判断，测试果然通过。然后我又发现了一个问题：在做异步测试的时候，每次都是这样sleep几秒再做断言。这样就会有问题：因为sleep几秒之后，请求也不一定返回。我同她讲，她的测试表现不稳定经常挂掉，一定有这个sleep的原因。于是带着这个思路，开始找异步测试的准确方法。
这个经历给我的心得是，要透过现象看本质，坚持自己的想法和思路。 - 做平台登陆
做本项目的登陆是个很难受的过程。首先，我们的paas平台是以iframe的形式嵌在客户已有的云平台中的。我们的登陆，首先需要验证用户是否通过已有云平台的身份认证。所以我们的登陆流程是：从云平台拿到用户的云平台token->验证该token->验证通过则生成paas平台自己的Iot token。用户拿到Iot token后，每次请求都带上token就可以了。在实现时，要从iframe里中的URL里拿到云平台token发送给后端校验，然后再把iot token保存在vuex中。每次刷新，就会重新走一遍登陆流程。做完后测试发现功能十分不稳定，登陆时而成功时而不成功。最后我们把自己写的代码排查了一遍发现并没有问题，然后猜测是云平台token验证机制有问题。与云平台供应商说明情况一起排查才发现，原来他们并没有实时把新的token传给我们，这样的话我们就可能拿着已过期的token去进行身份验证，结果当然是挂的。得知这个事实的我们是无语的，万万想不到我们是因为这个原因导致登陆不稳定。本来按照正常流程，我把token存在vuex里是没有问题的。但是在我拿到的云平台token可能可能过期的情况下，为了保证开发和测试稳定登陆，我只能尽可能不去走云平台这套登陆流程，尽量用我们自己的iot token去认证身份。如此便出了一个下策：一旦拿到iot token，就将其存放在localStorage中，只有在iot token失效或者用户手动清除localStorage时才重新拿云平台token走登陆流程。这种做法安全性降低了很多，但是在依赖不稳定的情况下，并没有更优雅的办法了。
收获：
- 前端的全局观
- 解决问题的思路
- 找库的思路
- 对api的理解
- vue从熟悉到熟练
- iot的粗逻辑
不足：
- 没有及时做总结
- 对后端的依然知之甚少
- 对权威没敢质疑
- 没有考虑前端性能
最后尤其想说的是我们的团队氛围真的很棒，连客户都称赞的2333。团队很小共8人，中途没有人员流动。首席和BA非常贴心，承包了很多脏活累活。senior的同事们也都乐于授教，总是不存在解决不了的问题。虽然听说一般local项目工期紧任务重加班多，但是我们几乎不需要加班，除了第一个迭代需要许多基础性的工作导致时间不够，或者迭代最后两天忙一些加一点班，总体来说节奏是很正常的。甚至还能每周一聚餐，不定期周末出游。希望以后经历的每个团队都能有这样的氛围和节奏呀～